home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000053_owner-urn-ietf _Fri Jan 31 13:37:24 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA05917 for urn-ietf-out; Fri, 31 Jan 1997 13:37:24 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA05911 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 13:37:21 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA27421  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:37:12 -0500
  5. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  6.           id <06735-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 19:32:13 +0100
  7. Date: Fri, 31 Jan 1997 19:32:11 +0100 (MET)
  8. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  9. To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  10. Cc: jayhawk@ds.internic.net, "Ron Daniel Jr." <rdaniel@lanl.gov>,
  11.         omar syed <osyed@lerc.nasa.gov>, URL mailing list <ietf-url@imc.org>,
  12.         urn-ietf@bunyip.com
  13. Subject: Re: [URN] Re: Relative URLs and URNs
  14. In-Reply-To: <199701311739.LAA04387@void.ncsa.uiuc.edu>
  15. Message-Id: <Pine.SUN.3.95q.970131192858.246S-100000@enoshima>
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; charset=US-ASCII
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. On Fri, 31 Jan 1997, Daniel LaLiberte wrote:
  24.  
  25. > Ryan Moats writes:
  26. >  > Just to make everyting clear, if the client does not understand the
  27. >  > namespace, should treat the NSS as an opaque string, yes? (At least,
  28. >  > I certainly hope so...)
  29. > 
  30. > Nothing else makes sense.
  31. > But maybe such a client should commit suicide. :-)
  32.  
  33. Not necessarily. With the number of URL schemes and URN namespaces
  34. increasing, as well as the complexity of other things the client has
  35. to do, it might be a very good implementation strategy to delegate
  36. all the URL/URN resolution stuff to a *local* server (proxy).
  37.  
  38. Regards,    Martin.
  39.  
  40.